1. Field of the Invention
The present invention relates to the field of computer software and, more particularly, to validating software objects within a grid environment.
2. Description of the Related Art
The majority of significant software projects conducted today are complex undertakings involving large teams of software developers with individual teams focusing on discrete project tasks. Each of these teams can operate in a semi-autonomous fashion and can utilize different software development tools, languages, and techniques. To integrate the various components of software projects, a variety of documents that include interface documents, requirements documents, and performance specifications are developed. While these configuration documents are typically complete and generally followed, sometimes deadlines result in implementation shortcuts as well as undocumented and/or unrecognized component requirements or shortcomings. The majority of the structural discrepancies are relatively benign and do not result in problematic behavior.
A portion of structural discrepancies, however, do cause unexpected system behavior, which is sometimes referred to as software glitches or software bugs. These bugs can be very difficult to detect, fix, and verify, especially when the bugs occur within geographically dispersed software. Geographically dispersed software can be defined as software with multiple components spread throughout multiple physical locations. A grid environment is an example of a computing environment where software is installed and utilized in a geographically disperse manner.
The grid environment can be a distributed computing environment where computing, application, storage, and/or network resources can be shared across geographically disperse organizations. An ideal grid computing environment can permit flexible, secure, coordinated resource sharing among dynamic collections of individuals, organizations, and resources. In the grid environment, a variety of computing resources that contribute to a virtual resource pool can be transparently utilized on an as-needed basis. Grid computing resources in the virtual resource pool can be treated as commodities or services, which can be consumed in a manner similar to the commercial consumption of electricity and water.
While grid computing may presently be at an early stage in its evolution, several grid computing environments have been successfully implemented. One noteworthy implementation is the NC BioGrid Project that was successfully implemented in the fall of 2001 to enable researchers and educators throughout North Carolina to pool computing resources for use in sequencing genes and related genetic research. Other notable grid implementations include SETI@home, the Drug Design and Optimization Lab (D2OL), and EUROGRID. Additionally, commercially available software products exist for establishing a customizable grid computing environment, such as Avaki's data grid from Avaki of Burlington, Me. and Grid MP Enterprise from United Devices of Austin, Tex. Further, a number of readily available toolkits and standards have been developed for creating a grid computing environment including, for example, the Globus Toolkit provided by the Globus project and the Open Grid Services Architecture (OGSA).
A grid computing environment can include multiple applications. Each application can include a set of computing resources that performs a series of related tasks. Examples of applications include, but are not limited to, word processors, database programs, Web browsers, development tools, drawing applications, image editing programs, and communication programs. The various computing resources for one application can be distributed across several different grids within a grid computing environment, wherein each grid can contain a myriad of diverse hardware components, such as communication lines, networking routers, servers, workstations, peripherals, intranets, and the like.
Testing and validation can be especially important within a grid environment because problems with one grid-enabled application can have cascading effects upon other applications. That is, since many different grid-enabled applications can share pooled resources, one malfunctioning application feature that overly consumes needed resources can affect multiple applications that share the commonly utilized resources. The interdependencies that exist among applications in a grid environment, however, make testing and validating individual applications and system components extremely difficult.
Conventional methods for validating grid-based software involve extrapolation. Extrapolation methods record small, finite, measurable increments of system resources. The recorded increments are applied to an extrapolation algorithm in order to verify that software within a grid location is functioning properly. This verification, however, is generally performed at the level of discrete software objects and based upon system variables and hardware that particular software objects affect. Unfortunately, many different sources and applications can utilize the verified software object. Accordingly, conventional extrapolation methods are inadequate for accurately validating discrete code segments within the context of a particular application or usage.